home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-houttuin-mapauth-00.txt < prev    next >
Text File  |  1993-06-07  |  54KB  |  1,417 lines
  1.  
  2. INTERNET-DRAFT                                         Jeroen Houttuin
  3. RARE WG-MSG                                               Klaus Hansen
  4.                                                           Serge Aumont
  5. ver. 2.2.                                                     May 1993
  6.                                    
  7.                                    
  8.                Address mapping functions and authorities
  9.                                    
  10.  
  11.  
  12. Abstract
  13.  
  14.    
  15.    This document defines the responsibilities and authorities for
  16.    defining, collecting and distributing RFC 1327 address mapping
  17.    rules. It clearly defines the items: mapping function, addressing
  18.    authority, administrative equivalence as well as a mechanism for
  19.    registering mapping authorities and administrative equivalence. This
  20.    mechanism is based on an extension of RFC 1327 mapping rules (during
  21.    the collection distribution process). No changes to already
  22.    installed gateway software are required.
  23.  
  24.  
  25. Status of this Memo
  26.  
  27.    
  28.    NB. The reader is assumed to have a solid understanding of X.400,
  29.    RFC 822 and RFC 1327. This document is produced by the RARE WG-MSG
  30.    Task Force on Mapping Authorities. Comments can be sent to the
  31.    authors, tf-mapauth@cosine-mhs.switch.ch , or to wg-msg@rare.nl.
  32.    Before sending comments, please read the 'About this document'
  33.    section.
  34.    
  35.    This document is an Internet Draft. Internet Drafts are working
  36.    documents of the Internet Engineering Task Force (IETF), its Areas,
  37.    and its Working Groups. Note that other groups may also distribute
  38.    working documents as Internet Drafts.
  39.    
  40.    Internet Drafts are draft documents valid for a maximum of six
  41.    months. Internet Drafts may be updated, replaced, or obsoleted by
  42.    other documents at any time. It is not appropriate to use Internet
  43.    Drafts as reference material or to cite them other than as a
  44.    "working draft" or "work in progress."
  45.    
  46.    Please check the I-D abstract listing contained in each Internet
  47.    Draft directory to learn the current status of this or any other
  48.    Internet Draft.
  49.    
  50.    Distribution of this memo is unlimited.
  51.  
  52.  
  53. About this document
  54.  
  55.    
  56.    This chapter explains the goals and reasons for choices made in the
  57.  
  58.  
  59. Houttuin, Hansen, Aumont        Expires November 1993          [Page 1]
  60.  
  61. INTERNET DRAFT                                               April 1993
  62.  
  63.  
  64.    remainder of the document.
  65.  
  66.  
  67. - Goals
  68.    
  69.    There are a number of problems this document is targeted to solve.
  70.    Some of these targets are by nature conflicting, so the presented
  71.    solution will have to be a compromise. We are aware that the
  72.    proposed solution will not fully satisfy all parties. However, we
  73.    believe that we present in this document a reasonable, pragmatic and
  74.    feasible approach. Our goals are:
  75.      
  76.      - Agreement on the mapping function (see chapter 2). RFC 1327
  77.        defines the address mapping function by describing it in text,
  78.        which leaves room for some ambiguities. We need global agreement
  79.        on a precise function definition.
  80.      
  81.      - Agreement on mapping authorities. So far there has not been a
  82.        global consensus on the definitions of 'mapping authority',
  83.        'administrative equivalence' etc. Since these terms must be well
  84.        agreed upon before responsibilities and duties of parties
  85.        involved in the mapping process can be described, we need clear
  86.        definitions.
  87.      
  88.      - Although most experts agree that local mappings are an evil, it
  89.        must also be recognised that they cannot be abandoned for the
  90.        time being. Ignoring them is not realistic and will only create
  91.        more difficulties. Locally mapped addresses can at any time leak
  92.        out to the global level through so-called third-party-routed
  93.        mails. Recognising this fact, we believe that we should at least
  94.        try to gain more control over local mappings, whilst at the same
  95.        time strongly discouraging their use. Our approach treats the
  96.        registration of local mappings the same as this of normal
  97.        mappings, thus enabling the automatic refusal of local mappings
  98.        in case of conflicts.
  99.      
  100.      - We need clear algorithms and procedures to solve conflicts in
  101.        mapping rules.
  102.      
  103.      - The algorithms and procedures must be easy to automate and not
  104.        require adaptation of the installed gateway products.
  105.      
  106.      - If a transition in the collection and redistribution process of
  107.        mapping rules is needed, it must be a smooth transition from the
  108.        currently used procedures in the Internet and GO-MHS community.
  109.  
  110.  
  111. - Considerations
  112.    
  113.    One of the main issues to be addressed was that of local mappings.
  114.    The considerations in favour of our approach as opposed to the
  115.    current situation are listed below:
  116.  
  117.  
  118. Houttuin, Hansen, Aumont        Expires November 1993          [Page 2]
  119.  
  120. INTERNET DRAFT                                               April 1993
  121.  
  122.  
  123.      
  124.      Now
  125.          
  126.          - There exist no global rules for which local mappings are
  127.            allowed. Every gateway manager can add local mappings to the
  128.            distributed tables, even if they conflict with other rules.
  129.            Since it is not feasible to completely abandon local
  130.            mappings some time soon, this leads to anarchistic use of
  131.            local mappings.
  132.          
  133.          - Every gateway manager must check his own local mappings for
  134.            conflicts before merging them with the international tables.
  135.            This may sound like a welcome punishment for those who
  136.            insist on the use of local mappings; in practice however, it
  137.            is a well known source of errors.
  138.          
  139.          - No algorithm for deciding in case of conflicts.
  140.          
  141.          + Smaller international tables (R2X)
  142.      
  143.      Proposal
  144.          
  145.          - Larger international tables (only R2X, which will however
  146.            not become larger than X2R)
  147.          
  148.          + One agreed set of rules. If local mappings are collected,
  149.            verified and redistributed for use under certain well
  150.            defined conditions, control is gained over local mappings.
  151.            Invalid local mappings will be automatically overruled. If
  152.            invalid local rules are still being used in a gateway, the
  153.            gateway manager can easily be blamed of violating written
  154.            Internet requirements.
  155.    
  156.    Another choice that has to be explained is the tagging of individual
  157.    mapping rules. The disadvantages of this approach are:
  158.      
  159.      - Larger mapping tables during collection and redistribution.
  160.      
  161.      - Extra steps during collection and distribution. Note however
  162.        that extra steps will be necessary in any solution for checking
  163.        mapping authorities.
  164.    
  165.    It has been said that a better choice would be to tag mapping rules
  166.    in bunches. The disadvantages of such an approach however would be:
  167.      
  168.      - It is unlikely that a set of rules will have exactly the same
  169.        definer and exactly the same path of registries. The combination
  170.        of all this information is needed however to be able to decide
  171.        the administrative equivalence and validity of every single
  172.        rule. And in case of a mapping rule rejection, the source of a
  173.        single mapping rule must be traceable.
  174.      
  175.  
  176.  
  177. Houttuin, Hansen, Aumont        Expires November 1993          [Page 3]
  178.  
  179. INTERNET DRAFT                                               April 1993
  180.  
  181.  
  182.      - This solution would assume a semantics in the order in which
  183.        mapping rules are listed in a table, thus any implementation in
  184.        a non-serial database (DNS, X.500) structure would become more
  185.        complicated.
  186.    
  187.    Finally, proposals were made to not use the mapping rules themselves
  188.    for storing the authority information, but to use DNS or X.500
  189.    instead. Our main consideration in taking the inline registration
  190.    method was the following. It cannot be expected that every mapping
  191.    collection/redistribution point has access to X.500 or DNS. Many
  192.    gateways exist on islands, e.g. address gateways, which will only
  193.    allow end users to address persons in the other mail world in the
  194.    address format of that other world, but do not perform the actual
  195.    gatewaying themselves. The least common denominator of all involved
  196.    parties is access to the mapping rules, regardless whether these are
  197.    distributed to them per e-mail, ftp, X.500 or by any other method.
  198.    Since every involved party needs to get the mapping rules anyway,
  199.    this will even minimise overhead that would be created otherwise by
  200.    extra X.500/DNS querying for every single mapping rule.
  201.  
  202.  
  203. Contents
  204.  
  205.    Abstract                                                          1
  206.    Status of this Memo                                               1
  207.    About this document                                               1
  208.         - Goals                                                      2
  209.         - Considerations                                             2
  210.    Contents                                                          4
  211.    1. Introduction                                                   5
  212.         1.1 Address trees                                            5
  213.         1.2 Authorities, rights, and responsibilities                5
  214.         1.3 The registration process                                 6
  215.         1.4 Addressing authorities                                   6
  216.              1.4.1. Internet                                         7
  217.              1.4.2. X.400                                            7
  218.         1.5 Pruned subtrees                                          8
  219.    2. Mapping functions                                              8
  220.         2.1 Introduction                                             8
  221.         2.2 Function definition                                      9
  222.         2.3 Ideal situation                                         11
  223.         2.4 Reality                                                 11
  224.    3. Mapping authorities                                           13
  225.         3.1 Administrative equivalence (AE)                         13
  226.         3.2 Mapping registries (MRs)                                14
  227.         3.3 A mechanism for claiming and tracing authorities        15
  228.         3.4 Using the extended mapping rules                        17
  229.    4 Registering Authorities                                        18
  230.         4.1 Top level authority registration                        18
  231.         4.2 Authentication of mapping registries                    19
  232.    5. Guidelines                                                    20
  233.    A. Glossary                                                      21
  234.  
  235.  
  236. Houttuin, Hansen, Aumont        Expires November 1993          [Page 4]
  237.  
  238. INTERNET DRAFT                                               April 1993
  239.  
  240.  
  241.    B. Initial top level mapping registries                          22
  242.         B.1. X.400 to RFC 822                                       22
  243.         B.2. RFC 822 to X.400                                       22
  244.    C. Bibliography                                                  23
  245.    D. Table pre-processor                                           24
  246.    E. Authors' addresses                                            24
  247.  
  248.  
  249. 1. Introduction
  250.  
  251.    
  252.    RFC 1327 defines a mapping between X.400(84/88) and RFC 822
  253.    addresses. The requirement for co-ordinated mapping and gateway
  254.    tables is included in the RFC to ensure smooth interworking. This
  255.    document describes the co-ordination procedures to be used for RFC
  256.    1327 gateways connected to the Internet and the GO-MHS community. It
  257.    is highly desirable that also other networks using RFC 1327 gateways
  258.    use these guidelines.
  259.    
  260.    Note that for brevity this document does not always follow the
  261.    normal conventions for representing X.400 domains (see [JHtut]). If
  262.    needed, the slash separated notation is used while omitting keywords
  263.    of the standard attributes, e.g. /S=plork/dom/pre/amade/nl/ instead
  264.    of /S=plork/O=dom/PRMD=pre/ADMD=amade/C=nl/
  265.  
  266.  
  267. 1.1 Address trees
  268.    
  269.    Addresses may span up a structured or an unstructured address space.
  270.    Only the former case is relevant in this document. Structured
  271.    addresses may be hierarchical, and thus shown as a path in a tree,
  272.    where the tree shows all possible addresses in a given domain. The
  273.    authority for registering an address (or a part of an address) may
  274.    be associated with the address tree, although it is conceptually a
  275.    separate tree.
  276.  
  277.  
  278. 1.2 Authorities, rights, and responsibilities
  279.    
  280.    An authority gets its authorisation from a higher authority, i.e. an
  281.    authority on a higher level, except when it is itself the highest
  282.    (or root) authority.
  283.    
  284.    An authority may assume authority in certain circumstances, although
  285.    it has not formally got it as described. This may be due to
  286.      
  287.       - it is unclear who has higher authority
  288.       - no higher authority has yet been set up
  289.       - the higher authority itself is assumed
  290.    
  291.    An assumed authority is temporary in nature, and registration rules
  292.    and register may be changed at a later point in time.
  293.  
  294.  
  295. Houttuin, Hansen, Aumont        Expires November 1993          [Page 5]
  296.  
  297. INTERNET DRAFT                                               April 1993
  298.  
  299.  
  300.    
  301.    An authority has normally some or all of following responsibilities:
  302.      
  303.      a. establishment of registrar and rules for registration
  304.      b. delegation of authority
  305.      c. establishment of rules for use
  306.      d. acting as primary source for validated data on registered items
  307.    
  308.    An assumed authority will be limited in establishing the rules in a
  309.    and c.
  310.    
  311.    An authority has the right to revoke registration according to the
  312.    set rules.
  313.  
  314.  
  315. 1.3 The registration process
  316.    
  317.    An item from a certain domain (e.g. name, address, mapping rule) is
  318.    registered by a registrar appointed by the authority in question,
  319.    according to rules defined at that time. The rules may be simple and
  320.    unwritten, or formal (even defined by a national standard). Often
  321.    the following steps are taken:
  322.         
  323.         a.The application for registering a certain item is validated,
  324.           to avoid conflicting claims to a certain item, or because
  325.           legal or technical conditions may have to be met. The
  326.           registering may cover single items or whole subtrees.
  327.         
  328.         b.If the conditions are met, the item is filed in the register
  329.           together with information about the applicant. In some cases
  330.           part of this information is passed to higher authorities. At
  331.           the same time it is decided which rights and responsibilities
  332.           is attached to the items.
  333.         
  334.         c.If the conditions for the use of an item are not being met,
  335.           or the registrant does not need the item anymore, the item is
  336.           remove from the register. It is up to the authority to decide
  337.           if the item may be used again.
  338.  
  339.  
  340. 1.4 Addressing authorities
  341.    
  342.    The difference between names and addresses, and thus between naming
  343.    authorities and addressing authorities is insignificant in the
  344.    context of this document.
  345.    
  346.    An addressing authority will create an addressing concept with
  347.    addressing guidelines that must be followed in (parts of) the
  348.    subtree. Underlying addressing authorities can then add their own
  349.    addressing concept etc.
  350.  
  351.  
  352.  
  353.  
  354. Houttuin, Hansen, Aumont        Expires November 1993          [Page 6]
  355.  
  356. INTERNET DRAFT                                               April 1993
  357.  
  358.  
  359. 1.4.1. Internet
  360.  
  361.    
  362.    The Internet contains several addressing domains, e.g. RFC 822
  363.    addresses, IP addresses, Ethernet addresses, host names. Only RFC
  364.    822 addresses are relevant in this document. An RFC 822 address has
  365.    the following structure:
  366.         
  367.         localpart@...sdom(2).sdom(1).tldom
  368.    
  369.    where "sdom" stands for "subdomain", "tldom" stands for "top level
  370.    domain", and a hierarchy of addressing authorities is considered to
  371.    be growing from left to right:
  372.         
  373.         localpart < sdom(n) < sdom(n-1) < ... < tldom
  374.    
  375.    Only the domainpart will be considered here (the localpart is - as
  376.    one would have expected - mainly a local matter).
  377.    
  378.    The root authority for the RFC 822 address tree resides at SRI-NIC,
  379.    and the top level branches have addresses that are either ISO 3166
  380.    two-letter country codes or are taken from a small table of domains
  381.    (e.g. net, edu, gov, com).
  382.    
  383.    Authority for top level addresses reside at a national organisation;
  384.    however a significant number of countries have no authority (and
  385.    whether authority then is at the root is an open question).
  386.  
  387.  
  388. 1.4.2. X.400
  389.  
  390.    
  391.    The root authority lies in the standard (a sort of "virtual
  392.    authority"). The first-level authority is more or less implicitly
  393.    delegated to the various countries according to ISO 3166. Exactly
  394.    who has the national authority is a national matter, and a "natural"
  395.    authority depends on whether CCITT X.400 or the equivalent ISO 10021
  396.    is to be followed. Some countries assumes that delegation of
  397.    authority is to the national tele-administration, others define the
  398.    authority in a national standard covering ADMD names, and in some
  399.    cases also PRMD names.
  400.    
  401.    The X.400 hierarchy has the following levels:
  402.         
  403.         PN < OU* < .. <  O < PRMD < ADMD < C
  404.                 
  405.                 PNPersonal Name
  406.                 OUOrganisational Unit(s)
  407.                 O       Organisation
  408.                 PRMD    Private Management Domain
  409.                 ADMD    Administration Management Domain
  410.                 C       Country
  411.  
  412.  
  413. Houttuin, Hansen, Aumont        Expires November 1993          [Page 7]
  414.  
  415. INTERNET DRAFT                                               April 1993
  416.  
  417.  
  418.    
  419.    Other attributes, such as Domain Defined Attributes (DDAs), may be a
  420.    part of an address, but are not unambiguously hierarchical in
  421.    nature.
  422.    
  423.    According to a national decision, authority over PRMD names is
  424.    either delegated to the ADMD level (each ADMD having a complete
  425.    addressing subtree) or kept at the national level. In the latter
  426.    case ADMD names and PRMD names may possibly all be taken from the
  427.    same set, thus making it possible to use a registered name as an
  428.    ADMD name, a PRMD name, or both.
  429.  
  430.  
  431. 1.5 Pruned subtrees
  432.    
  433.    An addressing authority does not automatically have control over all
  434.    branches of a sub-tree. Consider the following example:
  435.    
  436.    ----------------------------+----------------------------
  437.         X.400                  |          RFC 822
  438.    ----------------------------+----------------------------
  439.    CH:                         | .ch:
  440.    addr. authority: Swiss PTT  | addr. authority: SWITCH
  441.    ----------------------------+----------------------------
  442.     root                       |        root
  443.      /\                        |         /\
  444.     /  /CH/                    |        / .ch
  445.    /    /\                     |       /   /\
  446.        /  \                    |          /  \
  447.       /   /CH/ARCOM/           | .arcom.ch    \
  448.      /\    /\                  |        /\    /\
  449.     /  \  /  \                 |       /  \  /  \
  450.    /\  /\/\  /CH/ARCOM/SWITCH/ |
  451.               /\               |
  452.              /  \              |
  453.    ----------------------------+---------------------------
  454.    /CH/ARCOM/SWITCH/:          | .arcom.ch:
  455.    addr. authority: SWITCH     | addr. authority: Swiss PTT
  456.    ----------------------------+---------------------------
  457.    
  458.    The example also shows that a mapping registration tree will in
  459.    general not coincide with either of the complete addressing trees.
  460.  
  461.  
  462. 2. Mapping functions
  463.  
  464.  
  465.  
  466. 2.1 Introduction
  467.    
  468.    RFC 1327 describes the address mapping function, but at the same
  469.    time leaves room for some controversies. This chapter aims to
  470.  
  471.  
  472. Houttuin, Hansen, Aumont        Expires November 1993          [Page 8]
  473.  
  474. INTERNET DRAFT                                               April 1993
  475.  
  476.  
  477.    unambiguously define the address mapping function.
  478.    
  479.    Note that RFC 1327 defines 4 types of mapping rules:
  480.         
  481.         RFC 822 -> X.400
  482.         X.400 -> RFC 822
  483.         RFC 822 -> gateway X.400 domain
  484.         X.400 -> gateway RFC 822 domain
  485.    
  486.    Since the last type of rule is not being used in an internationally
  487.    co-ordinated way, use of such rules is considered a local matter and
  488.    is discarded in this document. If one absolutely wants to use such
  489.    rules, it is easy to extend the X.400 -> RFC 822 algorithm.
  490.  
  491.  
  492. 2.2 Function definition
  493.    
  494.    The mapping algorithm to be used by a gateway assumes the existence
  495.    of three tables, X2R, R2X and GW, which associate RFC 822 and X.400
  496.    domains. Left hand sides are unique in X2R and in the concatenation
  497.    of R2X and GW. The algorithm is defined as follows in pseudo code
  498.    (for a more comprehensive description, see [JHtut] and [1327]):
  499.    
  500.    RFC 822 -> X.400
  501.    
  502.    LHS encoded X.400 address?
  503.    y: unpack; GOTO END                                        [a]
  504.    n:
  505.        map2 entry?
  506.        y: use SA's of map2 entry; follow hierarchy for other SAs
  507.           localpart regular?
  508.           y: map localpart -> PN
  509.              GOTO END                                         [b]
  510.           n: GOTO DDA                                         [c]
  511.        n: gate entry?
  512.           y: use SAs of gate entry                            [d]
  513.           n: use SAs of local gateway                         [e]
  514.    :DDA: encode complete address in a DD.RFC-822
  515.    :END:
  516.    
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531. Houttuin, Hansen, Aumont        Expires November 1993          [Page 9]
  532.  
  533. INTERNET DRAFT                                               April 1993
  534.  
  535.  
  536.    X.400 -> RFC 822
  537.    
  538.    Address contains DD.RFC-822?
  539.    y: unpack DDA; GOTO END                                    [A]
  540.    n:
  541.        map1 entry?
  542.        y: use domains of map1 entry
  543.           other attributes regular?
  544.           y: follow hierarchy for other subdomains;
  545.              map PN-> localpart
  546.              GOTO END                                        [B]
  547.           n: follow hierarchy for other subdomains as
  548.              far as possible;
  549.              GOTO LHS with rest of attributes                [C]
  550.        n:                                                    [D]
  551.    :LHS: Left hand side encoding
  552.    :END:
  553.    
  554.    
  555.    Examples:
  556.    
  557.    Consider a gateway in country 'Z' which is known in the RFC 822
  558.    world as 'gw.z' and in the X.400 world as '/GW/Z/', and suppose only
  559.    the following mapping rules are used in this gateway:
  560.    
  561.    X2R:
  562.        C$A#a#
  563.    R2X:
  564.        a#C$A#
  565.    GW:
  566.        c.a#ADMD$D.PRMD$E.C$A#
  567.        b.c#ADMD$B.C$C#
  568.    
  569.    Then this gateway could perform the following mappings (the examples
  570.    follow the order of the pseudo code):
  571.    
  572.    [a] /S=jan/ADMD=amade/C=xy/@gw.z       /S=jan/ADMD=amade/C=xy/
  573.    [a] /S=jan/ADMD=amade/C=xy/@gw.y       /S=jan/ADMD=amade/C=xy/
  574.    [b] jan@c.b.a                                    /S=jan/C/B/A/
  575.    [b] jan@b.c.a                                    /S=jan/B/C/A/
  576.    [c] j_h@b.c.a                 /DD.RFC-822=j(u)h(a)b.c.a/B/C/A/
  577.    [d] jan@a.b.c                   /DD.RFC-822=jan(a)a.b.c/A/B/C/
  578.    [e] jan@d.b                        /DD.RFC-822=jan(a)d.b/GW/Z/
  579.    
  580.    [A] /DD.RFC-822=jan(a)xx.yy/GW/Z/                    jan@xx.yy
  581.    [A] /DD.RFC-822=jan(a)xx.yy/GW/Y/                    jan@xx.yy
  582.    [B] /S=jan/C/B/A/                                    jan@c.b.a
  583.    [C] /S=jan/GQ=jr/C/B/A/                    /S=jan/GQ=jr/@c.b.a
  584.    [C] /S=jan/D C/B/A/                          "/S=jan/D C/"@b.a
  585.    [D] /S=jan/B/C/                               /S=jan/B/C/@gw.z
  586.    
  587.  
  588.  
  589.  
  590. Houttuin, Hansen, Aumont        Expires November 1993         [Page 10]
  591.  
  592. INTERNET DRAFT                                               April 1993
  593.  
  594.  
  595.    Note that the sole fact that the gateway could perform a mapping
  596.    doesn't force it to do so. This depends on the preferred routing,
  597.    e.g. a gateway may choose not to map back (and gateway) a DDA mapped
  598.    address which contains the SAs of a remote gateway, but rather route
  599.    this message over X.400 to the addressed gateway which will then
  600.    have to perform the gatewaying. This is normal practice in most
  601.    algorithms for source routing, for which left-hand side encoding and
  602.    DDA mappings can also be used.
  603.  
  604.  
  605. 2.3 Ideal situation
  606.    
  607.    In the set of co-operative RFC 1327 gateways on the planet 'GW-manager-
  608.    utopia', there exist no mapping rules. Every address is mapped with LHS
  609.    encoding and DDA mapping. Although this configuration may ease the life
  610.    of gateway managers, it also creates many problems, mainly for the
  611.    users (see [JHtut] Chapter 3.3.2.).
  612.    
  613.    In the set of co-operative RFC 1327 gateways on the planet 'user-
  614.    walhalla', mapping of RFC 822 addresses and X.400 O/R addresses is
  615.    simple and divided in:
  616.      
  617.      - a set of RFC 822 and X.400 addresses (domains) with
  618.        administrative equivalence and bijective mappings between them.
  619.      - a set of O/R addresses which are RFC 822 visible by using left-
  620.        hand side encoding.
  621.      - a set of RFC 822 addresses which are X.400 visible by using DDA
  622.        mapping.
  623.    
  624.    This should be quite simple and each solution should be exclusive.
  625.    Therefore an address should have only one representation in each
  626.    address space.
  627.  
  628.  
  629. 2.4 Reality
  630.    
  631.    On the planet earth, the experience shows several cases where the
  632.    mapping between RFC 822 and X.400 domains is not bijective
  633.    (asymmetric mappings) and that such asymmetry is perhaps still
  634.    indispensable. It is useful to list the most common cases.
  635.  
  636.  - Fading out old address forms.
  637.    
  638.    If, for instance, a domain changed from one ADMD connection to
  639.    another, it may choose to support the old mapping for a certain
  640.    period. Since two X.400 domains are now associated with one and the
  641.    same RFC 822 domain, asymmetry is introduced.
  642.  
  643.  - An address tree is not always a real tree
  644.    
  645.    For instance, a PRMD may subscribe to several ADMDs and then one
  646.    mailbox can be identified by different O/R addresses. The following
  647.  
  648.  
  649. Houttuin, Hansen, Aumont        Expires November 1993         [Page 11]
  650.  
  651. INTERNET DRAFT                                               April 1993
  652.  
  653.  
  654.    mapping rules show an example:
  655.         
  656.         PRMD$blabla.ADMD$ .C$ch#blabla.ch#         [1]
  657.         PRMD$blabla.ADMD$switch.C$ch#blabla.ch#    [2]
  658.         PRMD$blabla.ADMD$eunet.C$ch#blabla.ch#     [3]
  659.         
  660.         blabla.ch#PRMD$blabla.ADMD$ .C$ch#         [4]
  661.         blabla.ch#PRMD$blabla.ADMD$eunet.C$ch#     [5]
  662.         blabla.ch#PRMD$blabla.ADMD$switch.C$ch#    [6]
  663.    
  664.    Since rules [4] [5] and [6] all have administrative equivalence (see
  665.    chapter 3.1), it is perfectly legal for EUnet to use mapping rule [5],
  666.    probably to ensure that subsequent mails will be routed over their
  667.    ADMD. Since these mapped address forms can leak out to the rest of the
  668.    world (third party problem), all reverse rules must be global. This
  669.    also results in asymmetry.
  670.    
  671.    The gateway's choice of which of the rules [4] [5] and [6] to use can
  672.    either be made according to local routing considerations or the
  673.    "blabla.ch" addressing authority can claim its preferred O/R address.
  674.    Not only routing, but also mapping depends on where you are (the most
  675.    trivial examples being the default left hand side encoding and DDA
  676.    mapping, but they can be mapped back without the use of mapping rules).
  677.  
  678.  - Subtrees without addressing authority
  679.    
  680.    The domains ".uucp" or ".bitnet" are used and usually well routed in
  681.    Internet networks but no addressing authority has ever registered them.
  682.    This implies that nobody can define an official mapping for those
  683.    domains. Therefore there are many ways to map such addresses, none of
  684.    which can be considered more valid or invalid than any of the others.
  685.    Some examples are:
  686.    
  687.    R2X mappings :
  688.    
  689.    bitnet#PRMD$bitnet.ADMD$ada.C$at#              [1]
  690.    bitnet#O$bitnet.PRMD$switch.ADMD$arcom.C$CH#   [2]
  691.    bitnet#PRMD$bitnet.ADMD$dbp.C$de#              [3]
  692.    
  693.    GW rules :
  694.    
  695.    bitnet#PRMD$bitnet.ADMD$0.C$FR#                [4]
  696.    
  697.    All those rules show different ways to relay X.400 messages to the
  698.    bitnet network. Rules [1], [2] and [3] have different semantics than
  699.    the domain association rules R2X. They are used to force the address of
  700.    a gateway into an O/R address. As such, they can be considered as the
  701.    RFC 987 equivalent of gateway rules. The usage of such rules is limited
  702.    to a specific area and every gateway has to choose which one to use.
  703.    Since these mapped address forms can leak out to the rest of the world
  704.    (third party problem), all reverse rules must be global. This also
  705.    results in asymmetry.
  706.  
  707.  
  708. Houttuin, Hansen, Aumont        Expires November 1993         [Page 12]
  709.  
  710. INTERNET DRAFT                                               April 1993
  711.  
  712.  
  713.    
  714.    These mappings are referenced as "local mapping" in the document [table-
  715.    creation-tutorial].
  716.  
  717.  
  718. 3. Mapping authorities
  719.  
  720.    
  721.    This chapter defines the parties involved in the process of
  722.    defining, collecting and distributing mapping rules within a
  723.    community. Note that a party may at any time choose to have certain
  724.    responsibilities and authorities represented by automated processes.
  725.    Another important generalisation is that the intuitively centralised
  726.    approach need not be followed strictly. If mapping rules are
  727.    maintained in a distributed way, distributed tools may become
  728.    necessary to enforce the responsibilities and authorities described
  729.    in this document. However, since conflicts must normally be solved
  730.    on an inter-personal basis, the defined parties must be clearly
  731.    defined: a central contact point for every involved party must be
  732.    available.
  733.  
  734.  
  735. 3.1 Administrative equivalence (AE)
  736.    
  737.    A mapping rule establishes a one-way correspondence between
  738.    addresses from two different domains. A mapping rule is used e.g. in
  739.    a gateway between mailing systems for transformation of addresses. A
  740.    mapping rule may map one address only (as in diku.dk --map-->
  741.    C=dk;A=dk400;P=minerva;O=diku), but it is more common to define
  742.    general rules for mapping a whole tree.
  743.    
  744.    A mapping rule is based on the existence of administrative
  745.    equivalence. This means that to define a valid mapping rule, one
  746.    must have authority over the relevant addresses in both addressing
  747.    domains. AE is defined as follows:
  748.    
  749.    A mapping rule has AE if and only if both sides of the rule have the
  750.    same addressing authority (or they agree on the rule), or all
  751.    mapping rules implied by this rule span up two subtrees that have AE
  752.    in every (at least one) corresponding pair of nodes.
  753.    
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767. Houttuin, Hansen, Aumont        Expires November 1993         [Page 13]
  768.  
  769. INTERNET DRAFT                                               April 1993
  770.  
  771.  
  772.    Examples
  773.    
  774.    Danish mapping rules (internal):
  775.         
  776.         RFC 822 addresses:
  777.                 
  778.                 id   domain         authority?
  779.                 --   ------         ----------
  780.                 
  781.                  A   teldk.dk       assumed
  782.                  B   y-net.dk       assumed
  783.                  C   ooo.dk         yes
  784.                  D   .dddd          assumed
  785.         
  786.         X.400 addresses:
  787.                 
  788.                 id  domain                       authority?
  789.                 --  ------                       ----------
  790.                 
  791.                 I   C=dk;A=teldk                 assumed
  792.                 II  C=dk;A=dk400;P=y-net         yes
  793.                 III C=dk;A=dk400;P=minerva;O=ooo yes
  794.                 IV  C=dk;A=dk400;P=inet;O=dddd   yes
  795.         
  796.         Mapping RFC 822 <--> X.400
  797.          
  798.           I ---> A   (ass to ass)     AE
  799.           B ---> II  (ass to auth)    Agreement exists
  800.           C ---> III (auth to auth)   AE
  801.           IV --> D   (auth to ass)    Local rule, no AE
  802.  
  803.  
  804. 3.2 Mapping registries (MRs)
  805.    
  806.    The following parties and corresponding responsibilities are
  807.    defined:
  808.    
  809.    Mapping rule originator
  810.      
  811.      define mappings
  812.    
  813.    Mapping registry (MR):
  814.      
  815.      Designate subordinate MRs per subdomain (822/X.400)
  816.      Collect mappings from subordinate MRs
  817.      Inform subordinate MRs about rejected mappings
  818.      Register mappings with next higher MR
  819.      Redistribute mappings received from next higher MR
  820.    
  821.    Ideally, there will b onmly one MR per community or branch
  822.    (subdomain) of the address tree.
  823.    
  824.  
  825.  
  826. Houttuin, Hansen, Aumont        Expires November 1993         [Page 14]
  827.  
  828. INTERNET DRAFT                                               April 1993
  829.  
  830.  
  831.    A top level MR (initially the MHS Co-ordination Service) is
  832.    responsible for the collection and redistribution of the complete
  833.    gateway and mapping tables.
  834.  
  835.  
  836. 3.3 A mechanism for claiming and tracing authorities
  837.    
  838.    In order to check for AE, and see who is responsible for certain
  839.    mapping rules, a formal mechanism for registering the relevant
  840.    authority information is needed. A commonly used strategy is to
  841.    merge this authorisaty information with the information that is to
  842.    be authorised (e.g. authority records in DNS). This approach has the
  843.    advantage that authorisaty information is automatically available at
  844.    the moment it is needed. Therefore, to each mapping rule some extra
  845.    fields are added. The first extar field indicates the AE:
  846.      
  847.      com#....C$it#n#
  848.      ch#PRMD$switch.ADMD$arcom.C$ch#y#
  849.    
  850.    Before registering a mapping rule at the next higher MR, a mapping
  851.    rule originator or MR adds an extra field to the mapping rule,
  852.    indicating its identity relative to this next higher MR. The top
  853.    level mapping registry could thus receive the following mapping
  854.    rule:
  855.      
  856.      ciba.ch#O$ciba.PRMD$eunet.ADMD$arcom.C$ch#y#eunet#switch
  857.    
  858.    More formally:
  859.    
  860.    Appendix F of RFC 1327 gives a syntax definitions of three kinds of
  861.    mapping rules:
  862.    
  863.    rules defined in RFC 1327                 named in this document
  864.    
  865.    mapping from O/R address to
  866.    Internet domains                          X2R
  867.    mapping from Internet domains
  868.    to OR-addresses using standard
  869.    attributes                                R2X
  870.    mapping from Internet domains to
  871.    RFC 822 using domain defined
  872.    attributes OR-addresses                   GW
  873.    
  874.    The general form is :
  875.    
  876.    R2X and GW: domain-syntax"#"dmn-or-address"#"
  877.    
  878.    X2R:        dmn-or-address"#"domain-syntax"#"
  879.    
  880.  
  881.  
  882.  
  883.  
  884.  
  885. Houttuin, Hansen, Aumont        Expires November 1993         [Page 15]
  886.  
  887. INTERNET DRAFT                                               April 1993
  888.  
  889.  
  890.    There a need to extend each rule with the following information :
  891.      
  892.      - Is there a administrative equivalence of both domains ?
  893.      - which addressing authority submit this rule
  894.      - who collect this rule
  895.    
  896.    The left side and right hand side of the rules are unchanged. Existing
  897.    conformant RFC 1327 gateways do not need any change.
  898.    
  899.    Mapping authority fields are added:
  900.    
  901.    R2X and GW:
  902.    
  903.    domain-syntax"#"dmn-or-address"#"AE"#"originator\
  904.    "#"registry"#"*(registry"#")
  905.    
  906.    X2R:
  907.    
  908.    dmn-or-address"#"domain-syntax"#"AE"#"originator\
  909.    "#"registry"#"*(registry"#")
  910.    
  911.    AE  = "Y" / "N"
  912.      
  913.      - Administrative equivalence is Y / N . If it's "Y" it means the
  914.        two domains are under control of the same addressing authority
  915.        or it exist a agreement between the two different addressing
  916.        authorities that guarantee this equivalence.
  917.    
  918.    originator= < non empty string without "#" >
  919.      
  920.      - if the administrative equivalence is "Y", this is the name of
  921.        the addressing authority over both domains, otherwise it is the
  922.        name of the authority that submitted this rule.
  923.    
  924.    Registry = < non empty string without "#" >
  925.      
  926.      - Registry : each registry are the named of the mapping registry
  927.        who accept this mapping and relay it to upper registry.
  928.    
  929.    Examples:
  930.    
  931.    glvt.fr#O$@.PRMD$GLVT.ADMD$atlas.C$FR#Y#glvt-cnrs#uniren1#PT#
  932.    
  933.    This rule shows administrative equivalence, it has been submitted by
  934.    glvt-cnrs via the University of Rennes (French registry) and the
  935.    COSINE MHS Project Team (PT), which is initially designated as the
  936.    GO-MHS community registry.
  937.    
  938.    bitnet#PRMD$bitnet.ADMD$atlas.C$fr#N#uniren1#uniren1#PT#
  939.    
  940.    This gateway rule is issued by the University of Rennes and without
  941.    administrative equivalence.
  942.  
  943.  
  944. Houttuin, Hansen, Aumont        Expires November 1993         [Page 16]
  945.  
  946. INTERNET DRAFT                                               April 1993
  947.  
  948.  
  949.  
  950.  
  951. 3.4 Using the extended mapping rules
  952.    
  953.    Mapping collection from subordinate registries
  954.    ----------------------------------------------
  955.    
  956.    Each registry will accept or refuse rules. Accepted rules are stamped
  957.    at the end with the registry name according to the following process :
  958.    
  959.    For each rule received : Does this rule conflict with other rules?
  960.       [important note : R2X and GW rules set are considered as a
  961.       single set when checking for conflicts]
  962.    No: accept (I.e. trust! This will be the default, to save us work)
  963.    Yes:
  964.      Does at least one rule claim AE ?
  965.      No: accept
  966.      Yes: For each of the conflicting mapping rules: check AE
  967.            AE: accept
  968.            No AE: Refuse
  969.    
  970.    Mapping rule conflicts are classified as follows:
  971.         
  972.         - Pure conflicts: two mapping rules have exactly the same left-
  973.           hand side.
  974.         - Exception conflicts: An exception rule without AE tries to
  975.           overrule a more general rule with AE.
  976.    
  977.    Subordinate registries are informed about rejected rules. This
  978.    subordinate registry must propagate the rejection notifications to
  979.    the appropriate subordinate registry or originator. This is
  980.    necessary because conflicts may not occur until a later stage in the
  981.    collection process.
  982.    
  983.    All accepted mappings are stamped with the registry identification
  984.    and registered with the next higher registry.
  985.    
  986.    When mappings arrive at the top-level registry, the redistribution
  987.    process starts.
  988.    
  989.    This collection process does not guarantee unique left-hand sides,
  990.    but ensures that in a remaining set of rules with the same left-hand
  991.    side, either each rule has AE, or not one rule has AE. The first
  992.    case can occur because the addressing tree is not a real tree (ADMD
  993.    = ; ADMD=0; other aliases); the second case covers the traditional
  994.    'local mappings'.
  995.    
  996.    Redistribution of mappings
  997.    --------------------------
  998.    
  999.    The collection of all mappings that were accepted by the top level
  1000.    registry is distributed in three tables, X2R, R2X and GW, using the
  1001.  
  1002.  
  1003. Houttuin, Hansen, Aumont        Expires November 1993         [Page 17]
  1004.  
  1005. INTERNET DRAFT                                               April 1993
  1006.  
  1007.  
  1008.    same channel of mapping registries (actually, this is a supertree of
  1009.    the rigistry tree, see chapter 4.1.c.). Before distributing the mapping
  1010.    rules, a registry may tailor the tables for a certain domain according
  1011.    to the algorithm described below. It is recommended though that this
  1012.    tailoring is done as close to the actual gateways as possible, i.e.
  1013.    ideally within the gateway.
  1014.    
  1015.    Use of mapping rules in a gateway
  1016.    ---------------------------------
  1017.    
  1018.    Here is a description of what can be a pre-processor for the 3 sets
  1019.    of mapping rules. The goal is to select the best set of rules and
  1020.    remove the extension before using the rules in the gateway. The GW
  1021.    software could be adapted to use the extended rules directly, or a
  1022.    script can generate the traditional 1327 tables from the distributed
  1023.    new-format tables, just before installing them in the gateway. The
  1024.    mapping of a domain remains as described in chapter 2, except there
  1025.    may be non-unique left-hand sides (again, R2X and GW are considered
  1026.    one set of rules here). In this case, a gateway must use the rule
  1027.    which is closest to the gateway (the metric being the distance in
  1028.    the tree of registries).
  1029.    
  1030.    This algorithm ensures that in every gateway, for each domain,
  1031.    exactly one mapping rule is left. It also allows different domains
  1032.    to automatically use different versions of equivalent rules,
  1033.    depending on their location in the authority tree.
  1034.  
  1035.  
  1036. 4 Registering Authorities
  1037.  
  1038.  
  1039.  
  1040. 4.1 Top level authority registration
  1041.    
  1042.    The following steps should be taken when a new mapping domain is
  1043.    introduced on the top level.
  1044.      
  1045.      a.The domain (country) finds a top-level mapping collecting
  1046.        organisation, which can act as the representative for the
  1047.        domain, and introduces the organisation to the other top-level
  1048.        mapping registries. The following information is given for the
  1049.        organisation:
  1050.          
  1051.          - Mapping domains (e.g. RFC 822 to X.400)
  1052.          
  1053.          - Mapping table designator for the organisation
  1054.          
  1055.          - Name, address, telephone and fax numbers for the
  1056.            organisation
  1057.          
  1058.  
  1059.  
  1060.  
  1061.  
  1062. Houttuin, Hansen, Aumont        Expires November 1993         [Page 18]
  1063.  
  1064. INTERNET DRAFT                                               April 1993
  1065.  
  1066.  
  1067.          - Name and e-mail address for the responsible person(s). The e-
  1068.            mail address is used to verify that the source of a given
  1069.            mapping is an authorised person.
  1070.          
  1071.          - Domain, for which this organisation has responsibility for
  1072.            collection of mappings.
  1073.      
  1074.      b.The collection organisation inside the domain is set up. It may
  1075.        be done in the following way.
  1076.          
  1077.          - In case a mapping authority for a certain address tree pair
  1078.            has been established, the relevant authority decides whether
  1079.            to rely on a general (default) rule or to define own mapping
  1080.            rules. In the former case, a collecting path from the
  1081.            authority up to the top-level registry is established, and
  1082.            an organisation designator (an abbreviated identifier for
  1083.            it) is defined for each part of the path. In the latter case
  1084.            the decision is propagated to the relevant registry.
  1085.          
  1086.          - The top-level registry may be the authority for certain
  1087.            mappings, or act simply as a registry. It defines a general
  1088.            (default) mapping for the whole domain, unless otherwise
  1089.            decided by the domain.
  1090.          
  1091.          - If authority cannot be established for certain mappings, it
  1092.            is marked in the mapping rule. A path is constructed as if
  1093.            authority had been established, from the relevant
  1094.            organisation to the top-level registry.
  1095.          
  1096.          - Note that the collection path need not coincide with the
  1097.            path in the address tree, as addressing authorities and
  1098.            mapping rule originators will often have no interest in the
  1099.            collection and distribution process.
  1100.      
  1101.      c.Distribution of top-level mappings will in principle follow the
  1102.        reverse path of the collection process, but as potentially the
  1103.        set of sites using mappings may be significantly larger that the
  1104.        set of organisations defining mappings, the distribution could
  1105.        be entirely independent of the collection process. It is
  1106.        entirely up to the domain to organise distribution of mappings.
  1107.  
  1108.  
  1109. 4.2 Authentication of mapping registries
  1110.    
  1111.    The mapping registries on the top level (e.g. country level) need to
  1112.    be identified by a designator, occurring in the mapping tables. To
  1113.    be able to know which organisation has a given designator, and which
  1114.    person (mail address) is authorised to publish mapping tables, some
  1115.    information has to be collected. This is similar to the COSINE
  1116.    documentation for the national networks. The final implementation of
  1117.    this documentation could be either table-based, DNS based, X.500
  1118.    based, or a combination of any of those. Although X.500 would seem a
  1119.  
  1120.  
  1121. Houttuin, Hansen, Aumont        Expires November 1993         [Page 19]
  1122.  
  1123. INTERNET DRAFT                                               April 1993
  1124.  
  1125.  
  1126.    natural choice, the same problems could occur as with the tagging
  1127.    and storing of the mapping rules themselves: not every gateway will
  1128.    have access to DNS or X.500 (e.g. address gateways). However, since
  1129.    the registry documentation is only to be used by the registries
  1130.    themselves, we would consider it a feasible requirement for each
  1131.    registry to have access to X.500. For the time being, a simple table
  1132.    based approach will be feasible, as conflicts will have to be solved
  1133.    by humans anyway.
  1134.    
  1135.    The information needed is:
  1136.         
  1137.         - Registry designator
  1138.         - Name, address, telephone and fax numbers for the organisation
  1139.         - Name and e-mail address for the responsible person(s). The e-
  1140.           mail address is used to verify that the source of a given
  1141.           mapping is an authorised person.
  1142.         - Domain, for which this organisation has responsibility for
  1143.           collection of mappings.
  1144.    
  1145.    Example:
  1146.    
  1147.    Registry: isi-dk
  1148.    Description: ISI-DK. A co-operation between Danish parties. Contact
  1149.    organisation is UNI-C, Bygning 305 DTH, DK-2800 Lyngby, Denmark.
  1150.    Telephone: +45 45 938355, Fax: +45 45 930220
  1151.    Responsible: Erik Lawaetz
  1152.    822: Erik.Lawaetz@uni-c.dk
  1153.    X.400: C=dk;A=dk400;P=minerva;O=uni-c;S=Lawaetz;G=Erik
  1154.    X.400-domains: C=dk;A=dk400;P=minerva
  1155.    822-domains: all sub-domains in ".dk" except "teldk.dk" and
  1156.    "dk400.dk"
  1157.    
  1158.    The exact syntax for this information will in a next version of this
  1159.    document be aligned with [UE93].
  1160.  
  1161.  
  1162. 5. Guidelines
  1163.  
  1164.    
  1165.    It is recommended that whoever defines a mapping rule informs the
  1166.    mapped subtrees that an implicit mapping for their domains exists.
  1167.    
  1168.    Every mapping registry is recommended to have X.500 access.
  1169.    
  1170.    The use of local mappings is strongly discouraged. Instead, the
  1171.    definition of GW entries for such domains is encouraged. Please note
  1172.    that also GW entries without AE will be rejected if one GW rule with
  1173.    AE exists.
  1174.    
  1175.    The originator and registry strings to be used as tags in the
  1176.    mapping rules should be as short as possible.
  1177.    
  1178.  
  1179.  
  1180. Houttuin, Hansen, Aumont        Expires November 1993         [Page 20]
  1181.  
  1182. INTERNET DRAFT                                               April 1993
  1183.  
  1184.  
  1185.    Justified by registry overhead, it is recommended to minimise the
  1186.    distance (in the registry tree) between the top level registry and
  1187.    the originators cq. gateways. This means that the introduction of
  1188.    any not strictly necessary MR is discouraged.
  1189.  
  1190.  
  1191. A. Glossary
  1192.  
  1193.      
  1194.      - Assumed authority: Temporary authority assumed in the absence of
  1195.        a higher authority, or because a higher authority has only
  1196.        assumed authority.
  1197.      
  1198.      - Authority: A combination of rights and responsibilities in a
  1199.        given context. Examples are the right to delegate authority, the
  1200.        right to define a mapping or override downwards mappings, and
  1201.        the responsibility to validate mappings.
  1202.      
  1203.      - Confirmed authority: Authority established either by natural
  1204.        rights, or by delegation from a higher authority.
  1205.      
  1206.      - Delegation: Attributes may be propagated downwards (to branching
  1207.        points in the tree further away from the root) by delegation.
  1208.        Attributes are e.g. the right to add new subtrees, or the right
  1209.        to use the names or addresses formed by the subtrees.
  1210.      
  1211.      - Downwards: Away from the root.
  1212.      
  1213.      - Explicit mapping rule: rule that is stated in a mapping table
  1214.      
  1215.      - Implicit mapping rule: mapping for subtrees implied by an
  1216.        explicit mapping rule.
  1217.      
  1218.      - Pruned subtree: A tree with one or more complete branches
  1219.        removed.
  1220.      
  1221.      - Registration: The process of registering e.g. names, addresses
  1222.        or mapping rules, according to rules defined by an authority,
  1223.        for a given domain (set of names, set of addresses, mapping
  1224.        context). Registration covers e.g. filing the item in question
  1225.        and related information about who registered, and (depending on
  1226.        the rules) validation of the application. Inquiries as to the
  1227.        contents of the register may or may not be allowed, depending on
  1228.        the rules.
  1229.      
  1230.      - Scope: Authorities, registration, trees, and mappings are only
  1231.        valid in a certain context, called its scope.
  1232.      
  1233.      - Subtree: A complete tree that is a part of another tree, i.e.
  1234.        where the root is a branching point of in a tree.
  1235.      
  1236.  
  1237.  
  1238.  
  1239. Houttuin, Hansen, Aumont        Expires November 1993         [Page 21]
  1240.  
  1241. INTERNET DRAFT                                               April 1993
  1242.  
  1243.  
  1244.      - Tree: The classical computer science tree, with the root
  1245.        upwards. In this context, each arc (branch) bears a part of an
  1246.        address or name. A path from root to a leaf thus defines a
  1247.        complete name or address.
  1248.      
  1249.      - Upwards: Towards the root.
  1250.  
  1251.  
  1252. B. Initial top level mapping registries
  1253.  
  1254.  
  1255.  
  1256. B.1. X.400 to RFC 822
  1257.    
  1258.    Domain/
  1259.    Country  Org.            Organisation & responsible design.
  1260.    =======  ====            =================================
  1261.    AT       aconet          ACOnet Christian Panigl
  1262.    BE       iihe            ULB/Helios-B group, Eftimios Tsigros
  1263.    BR       dfn             DFN, Peter Kaufmann
  1264.    CA       cdn             CDNnet, Dave Brent
  1265.    CH       switch          SWITCH, Felix Kugler
  1266.    CN       dfn             DFN, Volkmar Kobelt
  1267.    DE       dfn             DFN, Volkmar Kobelt
  1268.    DK       isi-dk          ISI-DK, Erik Lawaetz, Klaus Hansen
  1269.    ES       iris            redIRIS/FUNDESCO, Ignacio Martinez
  1270.    FI       funet           FUNET, Marko Kaittola, Teemu Kurki
  1271.    FR       uniren1         CRI/Universite de Rennes1, Serge Aumont
  1272.    GB       janet           JANET
  1273.    GR       ariadne         ARIADNE Network, Yannis Corovesis
  1274.    IE       ucd             University College Dublin, Niall O'Reilly
  1275.    IN       ernet           ERNET, ???
  1276.    IS       isanet          ISAnet, Marius Olaffsen
  1277.    IT       infn            CNAF INFN, Claudio Allocchio
  1278.    LT       litnet          LITNET, Petras Sulcas
  1279.    LU       restena         RESTENA, Alain Frieden
  1280.    NL       surfnet         SURFNET, Aad Boer
  1281.    NO       uninett         SINTEF, Harald Eikrem, Harald Alvestrand
  1282.    PT       inesc           INESC, Henrique Silva
  1283.    SE       sunet           Chalmers, Per Andersson
  1284.    SI       si-ac           Jozef Stefan Institute, Avgust Jauk
  1285.    US       xnren           UW-Madison, Allan Cargille
  1286.    YU       yunac           ???, Avgust Jauk, Marko Bonac
  1287.    ZA       uninet          UNINET, Rob Brain
  1288.  
  1289.  
  1290. B.2. RFC 822 to X.400
  1291.    
  1292.    Identical to table for X.400 to RFC 822, except for he following
  1293.    entries
  1294.    
  1295.  
  1296.  
  1297.  
  1298. Houttuin, Hansen, Aumont        Expires November 1993         [Page 22]
  1299.  
  1300. INTERNET DRAFT                                               April 1993
  1301.  
  1302.  
  1303.    Domain/
  1304.    Country     Org.        Organisation and responsible design.
  1305.    =======     ====        =================================
  1306.    CH          switch      SWITCH, Felix Kugler
  1307.    CH-EUNET    ch-eu       CH EUNET, Simon Poole
  1308.    US          xnren       UW-Madison, Allan Cargille
  1309.    US-ES esnet       ESnet, Tony Genovese
  1310.    
  1311.    Table: RFC 822 domains for which national authorities assume local
  1312.    responsibility:
  1313.      
  1314.      COM
  1315.      EDU
  1316.      GOV
  1317.      MIL
  1318.      NET
  1319.      ORG
  1320.      NATO
  1321.      ARPA
  1322.      BITNET
  1323.      UUCP
  1324.  
  1325.  
  1326. C. Bibliography
  1327.  
  1328.       
  1329.       821         Jonathan B. Postel, "Simple Mail Transfer Protocol",
  1330.                   RFC 821, University of Southern California, August
  1331.                   1982
  1332.       
  1333.       822         Crocker, D., "Standard of the Format of ARPA Internet
  1334.                   Text Messages", RFC 822, UDEL, August 1982.
  1335.       
  1336.       1327        Hardcastle-Kille, S., "Mapping between X.400(1988) /
  1337.                   ISO 10021 and RFC 822", RFC 1327 & RARE Technical
  1338.                   Report 2, UCL, May 1992.
  1339.       
  1340.       JHtut       Houttuin, J., "A tutorial on RFC 822 <-> X.400
  1341.                   gatewaying", Internet-Draft draft-houttuin-rfc1327-
  1342.                   tutor-02.txt, draft-houttuin-rfc1327-tutor-02.ps,
  1343.                   RARE Secretariat, February 1993.
  1344.       
  1345.       UE93        Eppenberger, U., "Routing coordination for X.400 MHS
  1346.                   services within a  multi protocol / multi network
  1347.                   environment", Internet-Draft draft-ietf-x400ops-
  1348.                   service-coordination-03.txt, SWITCH, December 1992.
  1349.       
  1350.       X.4xx(84)   CCITT Recommendations X.400 - X.430. Data
  1351.                   Communication Networks: Message Handling Systems.
  1352.                   CCITT Red Book, Vol. VIII - Fasc. VIII.7, Malaga-
  1353.                   Torremolinos 1984
  1354.       
  1355.  
  1356.  
  1357. Houttuin, Hansen, Aumont        Expires November 1993         [Page 23]
  1358.  
  1359. INTERNET DRAFT                                               April 1993
  1360.  
  1361.  
  1362.       X.4xx(88)   CCITT Recommendations X.400 - X.420. Data
  1363.                   Communication Networks: Message Handling Systems.
  1364.                   CCITT Blue Book, Vol. VIII - Fasc. VIII.7, Melbourne
  1365.                   1988
  1366.  
  1367.  
  1368. D. Table pre-processor
  1369.  
  1370.    
  1371.    Example perl script for table pre-processing to be written.
  1372.  
  1373.  
  1374. E. Authors' addresses
  1375.  
  1376.    
  1377.    Jeroen Houttuin
  1378.    RARE Secretariat
  1379.    Singel 466-468
  1380.    NL-1017 AW  Amsterdam
  1381.    Phone +31 20 639 1131
  1382.    Fax   +31 20 639 3289
  1383.    Mail  houttuin@rare.nl
  1384.    
  1385.    Klaus Hansen
  1386.    Department of Computer Science (DIKU)
  1387.    University of Copenhagen
  1388.    Universitetsparken 1
  1389.    DK-2100  Copenhagen
  1390.    Phone +45 35 32 18 18
  1391.    Fax   +45 52 32 14 01
  1392.    Mail  khan@diku.dk
  1393.    
  1394.    Serge Aumont
  1395.    CRI/Universite de Rennes1
  1396.    Av. du General Leclercs
  1397.    F-35042  Rennes Cedex
  1398.    Phone +33 99 84 71 00
  1399.    Mail  Serge.Aumont@univ-rennes1.fr
  1400.  
  1401.  
  1402.  
  1403.  
  1404.  
  1405.  
  1406.  
  1407.  
  1408.  
  1409.  
  1410.  
  1411.  
  1412.  
  1413.  
  1414.  
  1415.  
  1416. Houttuin, Hansen, Aumont        Expires November 1993         [Page 24]
  1417.